Location-based presentations of ticket opportunities

ABSTRACT

Location-based information is used to estimate which tickets are likely to be unused and to provide channels through which such tickets can be reassigned to others capable of attending the appropriate event. Locations of users (e.g., ticket holders or users interested in an event) are tracked (e.g., by tracking a user device or determining whether the user has redeemed other related tickets, such as a parking voucher), and it is estimated whether and/or when the user could arrive at the event. If it is unlikely that a ticket holder will be able to arrive at the event, an electronic offer can be presented to the ticket holder to surrender the ticket (which may result in a partial or full compensation). If the ticket is surrendered, the ticket can be electronically offered to another user selected based on the user&#39;s location and/or relationship to the initial ticket provider.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of and priority to U.S. Provisional Application No. 61/837,288, filed on Jun. 20, 2013, which is hereby incorporated by reference in its entirety for all purposes.

BACKGROUND

This disclosure relates in general to methods and systems for identifying users based on location-based predictions of actual or possible event attendance.

Conventionally, if on the day of a ticketed event a ticket holder cannot attend the event, the ticket holder has few options available to make use of the ticket because there is almost no time left to market the ticket. Consequentially, the ticket holder may give the ticket away or let it go unused, thereby sacrificing an amount paid for the ticket. The drawbacks are not one-sided. Others may desire to use the ticket, as the event may be sold out or the ticket may offer, e.g., seating advantages. Providing the ticket to such an interested person may be difficult due to, e.g., the ticket holder not knowing the person or not being able to easily communicate with, collect payment from, or provide the ticket to the person.

SUMMARY

In one embodiment, the present disclosure provides a method and system for utilizing location-based information to estimate which tickets are likely to be unused and to provide channels through which such tickets can be reassigned to others capable of attending the appropriate event. In one instance, locations of users (e.g., ticket holders or users interested in an event) are tracked (e.g., by tracking a user device or determining whether the user has redeemed other related tickets, such as a parking voucher). Based on the location, it is estimated whether and/or when the user could arrive at the event. If it is unlikely that a ticket holder will be able to arrive at the event (e.g., by the start of the event or at a different threshold), an electronic offer can be presented to the ticket holder to surrender the ticket (which may result in a partial or full compensation). If the ticket is surrendered, the ticket can be electronically offered (for free or for a price) to another user selected based on the user's location and/or relationship to the initial ticket provider (e.g., based on those in a shared season-ticket group).

In some embodiments, a ticket management system is provided for estimating user locations and presenting location-sensitive ticket offers. A ticket database identifies, for each ticket in a set of tickets for an event, an assignment indicating whether the ticket has been assigned to a user and an identifier of any user to whom the ticket is assigned. An offer database identifies a location and a time of the event. A locator accesses the offer database to identify the location of an event and the time of the event and estimates a current location of a user. An attendance predictor that predicts whether the user will be able to attend the event, the prediction being based on the location of the event, the time of the event and the estimated current location of the user. An offer engine determines, based on the prediction of whether the user will be able to attend the event, that an offer is to be presented to the user. The offer engine also generates the offer. The offer indicates that acceptance of the offer will cause an assignment of a ticket of the set of tickets for the event to change. The offer engine further presents the offer to the user and detects an acceptance of the offer from the user. A ticket assigner changes, in response to the detection of the acceptance, the assignment of the ticket in the ticket database.

In some embodiments, a method for estimating user locations and presenting location-sensitive ticket offers is provided. An offer database that identifies a location and a time of an event is accessed. Based on the access to the offer database, the location and time of the event are identified. A current location of a user of a ticket management system is estimated. A prediction is made as to whether the user will be able to attend the event, the prediction being based on the location of the event, the time of the event and the estimated current location of the user. Based on the prediction of whether the user will be able to attend the event, it is determined that an offer is to be presented to the user. The offer is offered, and an there is an indication that acceptance of the offer will cause an assignment of a ticket of a set of tickets for the event to change in a ticket database. The ticket database identifies, for each ticket in the set of tickets for the event. An assignment indicates whether the ticket has been assigned and an identifier of any user to whom the ticket is assigned. The offer is presented to the user. An acceptance of the offer from the user is detected. In response to the detection of the acceptance, the assignment of the ticket is changed in the ticket database.

In some embodiments, a ticket management system is provided for estimating user locations and presenting location-sensitive ticket offers. The ticket management system includes one or more processors and one or more memories coupled with the one or more processors. The one or more processors and one or more memories are configured to perform a method disclosed herein.

Further areas of applicability of the present disclosure will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description and specific examples, while indicating various embodiments, are intended for purposes of illustration only and are not intended to necessarily limit the scope of the disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure is described in conjunction with the appended figures:

FIG. 1 depicts a block diagram of an embodiment of a ticket interaction system;

FIG. 2 depicts a block diagram of an embodiment of ticket management system;

FIG. 3 illustrates a flowchart of an embodiment of a process for assigning a ticket for an event to a user;

FIG. 4 illustrates a flowchart of an embodiment of a process for presenting a ticket holder with an offer to surrender a ticket;

FIG. 5 illustrates a flowchart of an embodiment of a process for predicting whether a ticket holder will attend an event;

FIG. 6 illustrates a flowchart of an embodiment of a process for predicting whether a ticket holder will attend an event;

FIG. 7 illustrates a flowchart of an embodiment of a process for offering a surrendered ticket to another user;

FIG. 8 illustrates a flowchart of an embodiment of a process for identifying users to whom a surrendered ticket will be offered;

FIG. 9 illustrates a flowchart of an embodiment of a process for identifying users to whom a surrendered ticket will be offered;

FIG. 10 illustrates a flowchart of an embodiment of a process for identifying users to whom a surrendered ticket will be offered;

FIG. 11 illustrates a flowchart of an embodiment of a process for identifying users to whom a surrendered ticket will be offered;

FIG. 12 depicts a block diagram of an embodiment of a computer system; and

FIG. 13 depicts a block diagram of an embodiment of a special-purpose computer system.

In the appended figures, similar components and/or features can have the same reference label. Further, various components of the same type can be distinguished by following the reference label by a dash and a second label that distinguishes among the similar components. If only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label.

DETAILED DESCRIPTION

The ensuing description provides preferred exemplary embodiment(s) only and is not intended to limit the scope, applicability or configuration of the disclosure. Rather, the ensuing description of the preferred exemplary embodiment(s) will provide those skilled in the art with an enabling description for implementing a preferred exemplary embodiment. It is understood that various changes can be made in the function and arrangement of elements without departing from the spirit and scope as set forth in the appended claims.

Referring first to FIG. 1, a block diagram of an embodiment of a ticket interaction system 100 is shown. Users 105 and event providers 115 (e.g., a sports team manager or a vendor operator) can interact with a ticket management system 150 via respective devices 110 and 120 and a network, such as the Internet 140 or a wide area network (WAN), local area network (LAN) 114 or other backbone. In some embodiments, ticket management system 150 is made available to one or more of users 105 and/or event providers 115 via an app (that can be downloaded to and executed on a portable electronic device) or a website. It will be understood that, although only two users 105 and one event provider 115 are shown, system 100 can include different numbers of users 105 and/or event providers 115.

Using the ticket management system 150, an event provider 115 can identify an event, a price of attending the event, a date or dates of the event, a location or locations of the event, etc. Examples of events for which tickets can be obtained include sporting events, concerts, meals, shows, movies, lectures and amusement parks. Event provider 115 can further identify one or more times (which can include a date) or time periods for the event. For example, event provider 115 can indicate that a pre-game show begins at 1 pm EST and the game begins at 1:15 pm EST, or event provider 115 can indicate that lecture begins at 7 pm on Apr. 15, 2013 and will last three hours. Event provider 115 can identify a location of the event (e.g., a street address or venue name) and/or an expiration time (e.g., the ticket being invalid after Aug. 30, 2013). As described further below, ticket management system 150 can use the information provided by event provider 115 to allocate tickets for the event, generate an offer and present offer information to users 105.

A first user 105-1 can then use the ticket management system 150 to identify offer information and/or to purchase a ticket for an event, after which it can be assigned to first user 105-1. Ticket management system 150 can use information from and/or pertaining to the ticket (e.g., information about the event) and location information to predict whether first user 105-1 will use the ticket. For example, system 150 can estimate whether it is likely or possible that first user 105-1 will be able to commute from an estimated current location to an event location and arrive at the event before it begins. This assessment can be performed at a time relative to an event- or ticket-associated time (e.g., shortly before, at or shortly after an event start time or shortly before an expiration time). The assessment can be based on an event location and/or a location of first user 105-1. The latter location can be estimated based on a location of user device 110-1 or a determination as to whether another ticket related to the event or assigned to first user 105-1 has been redeemed (e.g., and, if so, where).

If it is predicted that first user 105-1 will not use the ticket, system 150 can provider first user 105-1 with an offer to surrender the ticket. Surrendering the ticket can be for free, for guaranteed payment (e.g., less than, equal to or more than an initial purchase price of value of the ticket) or for conditioned payment (e.g., conditioned upon the ticket being subsequently purchased by another user). If first user 105-1 accepts the surrender offer, the surrendered ticket can then be offered to one or more second users 105-2. The one or more second users 105-2 can include those who previously expressed interest in the event, who previously expressed interest in events of a type of the event, who are estimated to be at a location making it feasible and/or likely that they could arrive at the event on time, and/or who have a user relationship with the initial ticket holder (e.g., belonging to a shared season-ticket holder group or being part of a ticket-transfer club). If a second user 105-2 provides sufficient confirmation, information and/or payment, the ticket can then be reassigned to second user 105-2. In instances in which second user 105-2 pays for the surrendered ticket, part or all of the payment can be provided to, e.g., event-provider 115, an operator of ticket management system 150 and/or first user 105-1.

Referring next to FIG. 2, a block diagram of an embodiment of ticket management system 150 is shown. Ticket management system 150 can be, in part or in its entirety, in a cloud. In some instances, at least part of ticket management system 150 is present on a device, such as a user device 110 and/or event-provider device 120. For example, a payment engine 225 can be on user device 105, and a surrender-offer engine 250 can be in a cloud. In some instances, part of a component (e.g., part of surrender-offer engine 250) resides in a cloud and another part of the component resides in a device. Thus, ticket management system 150 can include a distributed system.

Ticket management system 150 includes an account engine 205, which generates accounts for users, stores accounts in account database 210, identifies users' accounts and accesses account data from account database 210. The account can be generated based on information provided by a user 105 and/or based on automatically detected data. For example, a user 105 can provide her name, email address, mailing address, billing address, credit card information, event types of interest and phone number. The operating system, make and model, and software capabilities of user device 110 can be automatically detected. In some instances, an account is accessed using login information. Thus, e.g., a user 105 can provide a username and password, each of which is stored in an account. When user 105 subsequently enters the username and password, other information from the account can be accessed. In another instance, an account is accessed using a device identifier, IP address, etc. Thus, e.g., account engine 205 can automatically detect this characteristic and store it in an account. When user 105 subsequently accesses system 150 using the same device or IP address, the device or IP address can be matched to the appropriate account and other information from the account can be accessed.

Account generation can occur for some or all users 105 accessing system 150. In some instances, the generation only occurs for users 105 who participate in generating the account (e.g., by agreeing to create an account and by providing information). In some instances, the generation occurs upon detecting particular user actions (e.g., interacting with a website provided by system 150 for a set period of time, attempting to purchase a ticket, or attempting to view price of tickets). Some system functions (e.g., purchasing a ticket) can require that a user 105 be logged into an account before utilizing part or all of the functions.

Ticket management system 150 includes a ticket-offer engine 215, which collects information about particular offers (e.g., from an event provider 115). For example, the information can identify an event or service for which the offer is available, time or times of the event or service, location or locations of the event or service, a price or prices for a ticket to or for the event or service, a minimum price for a ticket to the event or service, available seats, and/or an expiration time. The information can include a time period during which the offer is to be made available. The information can further identify restrictions on the offer. For example, an event provider 115 can limit a number of tickets available for a particular event.

Ticket-offer engine 215 aggregates the offer information, generates an offer record that includes the aggregated information and stores the offer record in offer database 220. Ticket-offer engine generates a presentation of the offer, which can include high-level information, short summaries and/or graphics, and presents (e.g., electronically via a provided user interface) the presentation of the offer to some or all users 105. The offer can be presented via an app, webpage, email, SMS, MMS, voice message, etc. The presentation can be automatically presented (e.g., upon a user 105 accessing the app or webpage) or presented in response to a query from user 105.

A user 105 can interact with ticket-offer engine 215 to respond to an offer by requesting tickets. The request can include a number of tickets; a seating area and/or a price threshold, range or amount. Ticket-offer engine 215 can determine whether the requested ticket(s) are available. If they are, ticket-offer engine 215 can offer specific tickets to user 105. This specific offer can include one or more seat numbers, one or more seating zones, one or more unique ticket identifiers, one or more event dates and/or times, one or more, event locations, and/or a price due for the ticket(s). Payment engine 225 can use account data and/or payment information provided in real-time by user 105 to collect the required payment for the ticket(s). For example, payment engine 225 can request payment information (e.g., a credit card number), identify payment information based on data previously stored in association with an account, request a user's agreement to pay a specific amount, complete the processing of a payment and/or indicate to user 105 whether a required payment was completed.

Upon receiving the user's consent to purchase the tickets and/or collecting payments, a ticket assigner 230 can assign the offered ticket(s). The ticket(s) can be assigned to designated ticket holder(s), which may be and/or include the purchasing user 105 and/or other identified individuals. Assigning the ticket(s) can include generating an electronic ticket or paper ticket (which can be sent by courier to the user or held at a location for the user). An electronic ticket can include a code (e.g., an optical code, barcode, alphanumeric code, etc.). The electronic ticket can include one that can be presented on a display of the user's mobile device, can include a file that can be printed, can include a token that can be electronically read (e.g., via an RF read, such as an NFC reader). The electronic ticket can be stored in association with an electronic record of an identification instrument of the user (e.g., a credit card/credit card number or driver's license number of the user), wherein when the user presents the identification instrument, the identification instrument may be read by an optical, magnetic, RF, or other scanner (or have an associated number manually entered via a keyboard), and system 150 may determine from an identifier scanned from the identification instrument whether there is a ticket for the event associated with the identification instrument. A generated ticket can include information about the ticket holder (e.g., the ticket holder's name), information about the event, and/or information about the specific tickets that were offered (e.g., seat numbers). Assigning the ticket(s) can include transmitting a ticket to user 105 (e.g., to the user's email) or granting access to a ticket via an account of the user. In some instances, assigning the ticket(s) includes associating a ticket identifier with a user identifier or ticket-holder identifier or updating a database to add a user or ticket-holder identifier to a list (e.g., for a given event).

Ticket assigner 230 can store any generated tickets and/or assignments in ticket database 235. Ticket database 235 can further include information indicating when the tickets were purchased, whether there are any restrictions on ticket transfer (e.g., identified by an event provider 115, identified based on a discount code, or identified based on a ticket type). Ticket database 235 can also include information about the purchasing user and/or ticket holders, such as information about respective mobile device(s) or other related tickets held by the user and/or ticket holder (such as parking vouchers or pre-game shows). Though not shown, ticket assigner 230 can further update an account of the ticket holder to reflect assignment of the ticket and/or to allow the ticket holder to access (e.g., view or print) the ticket.

Ticket assigner 230 informs ticket-offer engine 215 of the assignment, such that ticket-offer engine 215 does not subsequently offer the same ticket(s) to other users 105 and/or oversell the event. Ticket-offer engine 215 can update an offer stored in offer database 220 to reflect the assignment (e.g., by reducing a number of available tickets or removing an identifier of a ticket from an “available” list or database).

Despite the removal of assigned tickets, ticket-offer engine 215 can allow user 105 to continue to express their interest in specific tickets or groups of tickets (e.g., all tickets in a seating zone, all tickets within a price range, or all tickets for an event) despite their unavailability. For example, ticket-offer engine 215 can present a user 105 with an option which, if selected, will cause a notification to be transmitted (e.g., to the user's email or to the user's phone via a call or text message) if a ticket holder subsequently surrenders his ticket such that it then becomes available. As another example, ticket-offer engine 215 can present a user 105 with an option which, if selected, will cause a ticket to be automatically transferred to the user (i.e., reassigned to the user) if a ticket holder subsequently surrenders his ticket. Thus, the user 105 can opt to become a back-up ticket holder. Serving as a back-up ticket holder can require that the user submit a payment (e.g., which may or may not be refunded if the ticket is not surrendered to the user, and which may be part or all of the original ticket price), that the user agree in advance to pay for and/or accept the ticket upon it being surrendered and/or that the user identify any restrictions on accepting a surrendered ticket (e.g., a required notice prior to the event's start time). A user can indicate that he wishes to be a back-up for a particular ticket (e.g., Seat A42) or for a group of tickets (e.g., any two consecutive seats in seating section “Lodge”).

The number of users that can serve for a back-up may or may not be limited. For example, ticket-offer engine 215 can allow no more than two backups for a given ticket, or ticket-offer engine 215 can allow no more than 150 total backups for seating zones: Lower Level A-F. In some instances, back-up users are ranked, e.g., based on when a the users requested to be back-ups, an amount that the users are willing to pay for a surrendered ticket, an amount already paid to serve as back-ups, how much advance notice the users identified as being required to take a surrendered ticket, an account membership status, a number of tickets previously purchased from system 150, etc.

In some instances, ticket assigner 230 can automatically identify back-ups for a ticket. For example, ticket assigner 230 can identify users who are related, through system 150, to the ticket holder. For example, these users and the ticket holder can belong to a same season-ticket group or ticket-exchange group. Such group memberships can be identified in each group member's accounts, such that users in a group can be identified by searching through accounts for a group identifier. As another example, ticket assigner 230 can identify users who have an account with system 150 and have an address within a specified distance to an event location (potentially excluding those users who already have purchased tickets to the event). User identifications can also or alternatively depend on preferences or purchase history favoring a type of event or performer.

As an event nears, an attendance predictor 240 predicts which tickets ticket holders likely wish to surrender and/or which tickets will go unused. This prediction can be made based on estimating a location of the ticket holders. If an event's start time is near, ticket holders that are estimated to be far from an event location (e.g., based on a GPS location) or not being near the event (e.g., based on not having redeemed a parking voucher) may be predicted to miss the event.

Thus, attendance predictor 240 can access data from ticket database 235 that can aid in identifying a location of a ticket holder. This information can include, e.g., an identifier of a user device 115, a related ticket identifier or an account identifier. Using this information, a locator 245 can estimate the ticket holder's current location. For example, locator 245 can send a signal to a mobile device and request that it return its location and/or can receive location information. An estimated location can be determined (e.g., at a mobile device or at locator 245) based on GPS, cell-towers, and/or WiFi-access-point signals. In some instances, an app (e.g., provided by an operator of ticket management system 150) downloaded and installed on the mobile device estimates a current location. As another example, locator 245 can determine whether a related ticket (e.g., a parking voucher) has been redeemed and identify where the redemption occurred. As another example, locator 245 can trace an IP address based on a recent access to an account of the ticket holder and can associate the IP address with a location.

Locator 245 can then compare the estimated current location with a location of the event. This comparison can include identifying a separation distance and/or identifying one or more routes between the locations. The distance and/or routes can be used to estimate a transit time between the locations, which can account for current traffic conditions and/or speed limits. Locator 245 can then predict when, if the ticket holder is currently in route to the event or immediately leaves for the event, the ticket holder will be able to reach the event location. The prediction can include a single time and/or a range of times. The time(s) can be compared to a scheduled and/or predicted event start time and/or end time. Thus, e.g., locator 245 can estimate that, in a best-case scenario, a ticket holder would arrive at an event 45 minutes after it began.

Attendance predictor 240 can access a surrender-offer criterion (e.g., which can be the same across events or can be specific to an event type, an event provider or an event). Attendance predictor 240 can assess the criterion in view of the estimated ticket-holder location and/or an estimated (absolute or relative) arrival time. The assessment can include, e.g., comparing a time difference between the estimated arrival time and the event start time to a threshold, determining whether the estimated location was amongst the fifty furthest (relative to an event location) amongst estimated locations for all tickets for the event, weighting an estimated lateness variable based on a number of back-ups for a ticket, etc. In some instances, the criterion includes a factor or variable that accounts for when the criterion (e.g., relative to an event time) is being assessed. In some instances, different criteria are used based on when the criterion is being assessed. In some instances, the criterion is only evaluated during a fixed time or time period relative to an event time (e.g., 10 minutes before an estimated actual event start-time). The criterion can be designed such that satisfaction of the criterion suggests that a ticket holder may or likely will not be attending the event and/or may or likely would be interested in surrendering his ticket.

If the surrender-offer criterion is satisfied, a surrender-offer engine 250 generates a ticket-surrender offer. The ticket-surrender offer can include an identification of the event (e.g., its name, location and/or start time). The ticket-surrender offer can further include estimations generated by locator 245 (e.g., an earliest estimated arrival time, an estimated lateness, or an estimated minimum fraction of event that the ticket holder would miss). The ticket-surrender offer can include an expiration time, after which the offer is no longer open.

Surrender-offer engine 250 can determine a surrender price that could or would be provided to the ticket holder if he agrees to surrender the ticket. The surrender price can be determined, e.g., based on an amount that the ticket holder paid for the ticket, how many back-ups there are for the ticket, an amount that the back-ups have agreed to pay for the surrendered ticket, where back-ups are estimated to be located, an amount that the ticket would be remarketed (e.g., to back-ups, to users generally or to another entity) for, how many tickets to the event are available, when other tickets were purchased for the event (e.g., a sell-out date), a current value of the specific ticket or tickets for the event generally (e.g., based on other resale prices or auction prices), a quality of seat (e.g., seat location), an estimated probability as to how likely it is that the ticket holder will miss the event, and/or a time (e.g., relative to a scheduled or estimated start-time of the event) that the offer is to be presented to the ticket holder. The ticket-surrender offer can identify the surrender price. The surrender price can be less than, equal to or greater than an initial purchase price (e.g., depending on whether an event is sold out).

In some instances, ticket management system 150 does not set a surrender price. Rather, the ticket holder can be afforded the opportunity to set a price (which may or may not be bounded). In some instances, a recommended resale price or price range can be provided, which can be determined as similarly discussed above The ticket holder's surrender of the ticket can then be conditioned on whether another user will purchase the ticket such that the set price will be provided to the initial ticket holder. The price that the ticket would be offered to other users can be the price set by the ticket holder or a price otherwise based on the set price (but supplemented to include a fee for the transfer).

Thus, an illustrative ticket-surrender offer may state: “This is to remind you that the Ravens-Jets football game begins at 1:15 pm today. Based on the location of your mobile phone, it is estimated that you will, at the earliest, arrive at the stadium gate at 1:45 pm. If you wish to surrender the 3 tickets that you purchased for this event in exchange for $100, click here. You may surrender your tickets for this payment only until 12:45 pm.”

Another illustrative ticket-surrender offer may state: “You are estimated to arrive at the event venue 45 minutes after the scheduled beginning of the event if you take route 1 (along Olympic Boulevard) {link to directions}; You are estimated to arrive at the event venue 49 minutes after the scheduled beginning of the event if you take route 2 (along Pico Boulevard) {link to directions}; You are estimated to arrive at the event venue 54 minutes after the scheduled beginning of the event if you take route 3 (along Venice Boulevard) {link to directions}. If you are interested in surrendering your ticket for a partial refund, click here.”

Another illustrative ticket-surrender offer may state: “Based on your current location and parking congestion, we estimate that you will miss at least the first twenty minutes of the event. If you would like to attempt to resell your ticket to another user, click here to set your resale price. You will be notified if another user has accepted your resale offer within the next ten minutes.”

Surrender-offer engine 250 can transmit the offer to a ticket holder. For example, the offer can be included in an email, message (e.g., text message), webpage text, or phone call (e.g., an automated phone call) and sent to the user's email account, phone or browser. The offer can include a link, phone number or email address that the ticket holder can click on, call or message or email to, e.g., view further details regarding the offer or accept or decline the offer. In some instances, surrender-offer engine 250 can transmit multiple surrender offers to a ticket holder, which may be repeated transmissions of a same off or can vary in price (e.g., reducing a surrender price as the event nears). In some instances, surrender-offer engine 250 can terminate transmissions of such offer upon receiving an explicit decline of the offer from the ticket holder.

If surrender-offer engine 250 detects that the ticket holder has accepted the ticket-surrender offer, ticket assigner 230 can remove unassign the ticket to the user. The unassignment can include removing a ticket from ticket database 235, removing the original ticket holder from a list or database, and/or updating the ticket holder's account.

As a result of the unassignment, the ticket may be once again available. In some instances, the ticket-offer engine 215 can then offer the ticket to users 105. A price of the ticket can be less than, equal to or more than the price of the ticket when it was purchased by the original ticket holder. The price can be determined, e.g., based on how many tickets are available to the event, how soon the event will began (or how much of the event has already occurred), an amount that the ticket holder paid for the ticket, how many back-ups there are for the ticket, an amount the back-ups have agreed to pay for the surrendered ticket, when other tickets were purchased for the event (e.g., a sell-out date), a seat location, and/or a current value of the specific ticket or tickets for the event generally (e.g., based on other resale prices or auction prices). If a user 105 requests the ticket, payment can be collected and the ticket can be assigned as described above for the original ticket purchase.

Ticket-offer engine 215 can offer the ticket to all users, a subset of all users, all back-up users for the ticket or a subset of the back-up users for the ticket. In one instance, ticket-offer engine 215 selectively offers the ticket to users of back-up users near an event. Thus, account engine 205 can identify a set of users who may be interested in the event (e.g., based on event preferences, residence location, and/or purchase history) or can identify a set of applicable back-up users (e.g., with account data indicating that they are to serve as back-up users for the event, for particular types of tickets for the event, for the particular ticket of issue, for tickets surrendered by the original ticket holder, etc.). In some instances, account engine 205 also identifies data useful to determine a real-time location of the users, such as device identifiers.

The collected information can be passed to locator 245, which can estimate a current location of the users or back-up users in a manner similar to one described above. In some instances, instead, locator 245 merely uses users' or back-up users' addresses as estimates of their locations. Using the estimated locations, locator 245 can perform a similar distance and/or time estimations as described above, such as estimating when each user would be able to arrive at the event. Locator 245 can rank order the users or back-up users or select a subset of users or back-up users based on the estimations such that highly ranked users or users in the subset are those with estimated locations closest to the event location or estimated to be able to arrive at the event before its beginning or faster than other users.

Ticket-offer engine 215 can then iteratively offer the ticket to users in the subset or of highest ranks, progressing to a next subset or rank if the initial users do not accept or respond to the offer. The offer can be presented to the users in a manner similar to that described above with respect to the initial offer to the original ticket holder. If and/or once a user accepts the offer (e.g., and provides required payment or payment information), ticket assigner 230 can reassign the ticket to the user.

Thus, this illustrates how system 150 can employ an opt-in reassignment of a surrendered ticket. It will be appreciated that, in some other instances, a ticket is automatically reassigned to a back-up user. The automatic reassignment can occur, e.g., due to the back-up user's previous explicit or implicit agreement to serve as a back-up for a particular ticket or event or a particular group of tickets or events (e.g., all tickets in a particular season-ticket row throughout the season).

FIG. 3 illustrates a flowchart of an embodiment of a process 300 for assigning a ticket for an event to a user. Process 300 begins at block 305, where ticket-offer engine 215 accesses information about an offer. The information can identify an event (e.g., by identifying its name, performing artist/team(s), location, and/or start time), can indicate how many tickets (e.g., and their respective zones and/or seat numbers) are to be made available to the public or a portion of the public and/or can identify one or more ticket prices. The information can include that provided by an event provider by interacting with ticket-offer engine 215. Ticket-offer engine 215 stores the offer information in offer database 220 at block 315.

Ticket-offer engine 215 allocates tickets for the event at block 310. The allocation can include creating an event database (stored, e.g., in ticket database 235), with each database element corresponding to an offered ticket. Each element can further have an assignment status, which can be “unassigned” initially.

Ticket-offer engine 215 generates one or more offers to purchase tickets at block 315. The generated offer can identify the event, can indicate that tickets are available and/or can identify prices and/or seat locations for tickets. The generated offer can include text and/or graphics (e.g., of seating charts). Ticket-offer engine 215 presents the one or more offers to users at block 325. The offer can be presented, e.g., via a webpage, an app, SMS, MMS, voice message, email, etc. The offer can be presented by default (e.g., such that it is always presented on a webpage or such that it is presented on a webpage if a user's preferences align with the event), or it can be presented in response to a user query (e.g., for “comedy” events occurring in the next two weeks).

Ticket-offer engine 215 detects a ticket request, in response to the offer, from a user at block 330. The request can identify a number of requested tickets, a seating zone and/or one or more seat numbers. Payment engine 225 can determine an amount due for the requested tickets. Payment engine 225 then collects payment information from the user and obtains the user's consent to pay the determined amount at block 335.

Ticket assigner 230 assigns the requested ticket(s) to the user at block 340 and stores the assignment (e.g., in ticket database 235) at block 345. The assignment can include updating the event database to associate database elements corresponding to the requested tickets to the user and/or to identify such elements as having an “assigned” status. The assignment can also or alternatively include generating and/or providing the user with access to the appropriate electronic and/or paper ticket(s). It will be appreciated that process 300 can also apply to an offer for tickets to a group of events (e.g., a season-ticket offer), such that block 340 can include assigning a group of tickets corresponding to a group of events to the user.

FIG. 4 illustrates a flowchart of an embodiment of a process 400 for presenting a ticket holder with an offer to surrender a ticket. Process 400 begins at block 405, where attendance predictor 240 detects a pre-event time. For example, attendance predictor 240 can detect that it is a threshold amount of time before or after an event's start time or that it is the event's start time.

Attendance predictor 240 identifies one or more ticket holders at block 410. The identified ticket holders can include, e.g., all ticket holders, those in preferred seating locations, those with addresses far from the event or season-ticket holders. For a given ticket holder of the identified ticket holders, locator 245 estimates a location of the ticket holder at block 415. The location can be estimated by tracking a device, noting a ticket holder's home or work address, tracking access to an electronic ticket, etc. Locator 245 can further estimate a distance that the ticket holder is from the event, a commute time from the estimated location to the event and/or an earliest arrival time.

Attendance predictor 240 predicts whether the ticket holder will attend the event at block 420. The prediction can be based on location, distance, travel-time and/or arrival-time estimations. The prediction can also or alternatively be based on real-time or past communications from the ticket holder identifying whether he will attend the event and/or a probability that he will attend the event.

Surrender-offer engine 250 determines a price to offer the ticket holder for surrendering his ticket at block 425. Surrender-offer engine 250 presents the ticket holder with an offer to surrender the ticket at block 430. Surrender-offer engine 250 determines whether the ticket holder accepted the offer to surrender the ticket at block 435. If the offer is not accepted, process 400 returns to block 415 and continues with respect to another ticket holder. If the offer is accepted, process 400 continues to block 440 where payment engine 225 initiates a payment to the original ticket holder for the determined surrender-offer price (e.g., by crediting the original ticket holder's account, initiating an electronic payment, issuing a check, etc.). Ticket assigner 230 removes the assignment of the ticket to the ticket holder at block 445. The ticket can either be instantly reassigned to another user or can be identified as being available. The assignment removal can include invalidating a ticket, such as noting that a bar-code number is not to be accepted.

It will be appreciated that, while process 400 is shown as being an iterative process, it can be performed such that surrender offers are presented to multiple ticket holders simultaneously. In some instances, surrender offers are presented until a threshold number of offers have been accepted. It will further be appreciated that, rather than initiating process 400 with block 405, blocks 415 and 420 are repeatedly performed. Once a current time and estimated ticket-holder location results in an estimate of there being a low attendance probability, process 400 can continue to block 425. It will still further be appreciated that process 400 can be modified to include conditional acceptances. Specifically, the offer presented at block 430 can indicate that the ticket holder's surrender of the ticket will be conditioned upon whether another user purchases the ticket (e.g., for a predetermined price or a price set by the ticket holder). Blocks 440 and 445 can then occur once another user has agreed to purchased the ticket.

FIG. 5 illustrates a flowchart of an embodiment of a process 500 for predicting whether a ticket holder will attend an event. Process 500 begins at block 505, where locator 245 identifies whether a ticket holder granted permission to track her location. The permission status can be included in an account of the ticket holder and can be determined, e.g., based on input from the user entered while purchasing the ticket or setting up the account or based on whether the ticket holder changed a default permission in his account. In some instances, block 505 is omitted from process 500.

Locator 245 detects the ticket holder's current location at block 510. Locator 245 accesses information (e.g., from offer database 220 or from an electronic ticket) indicating where an event is to or is being held at block 515. Locator 245 determines one or more routes to the venue at block 520. The route(s) can include one(s) that are the least distance between the locations or are predicted to involve the shortest commute time (e.g., considering current traffic. traffic patterns and/or speed limits). Locator 245 estimates a travel time from the current location to the event location based on the routes. The estimation can include accounting for current traffic. traffic patterns and/or speed limits. Locator 245 estimates an earliest realistic arrival time at block 530. The estimation can be performed by adding the estimated travel time to a current time.

At block 540, locator 245 accesses, from offer database 220, an event time, which can include a time when the event is scheduled. In some instances, locator 245 first accesses an event start time and then estimates an actual event start time based on historic data or scheduled pre-event activities.

Attendance predictor 240 predicts whether the ticket holder will attend the event at block 540. This prediction can include, e.g., determining whether the estimated arrival time is before the event time or determining whether the estimated arrival time is before the event time plus a set delay time (e.g., such that the ticket holder is predicted as still being able to make an event if she can arrive before 10% of the event is over). (Thus, in some instances, process 500 can further include estimating an event duration and/or end time to determine times at which a particular fraction of the event will have occurred.)

It will be appreciated that, in some instances, process 500 can be modified to eliminate one or more of blocks 520-535, and the prediction at block 540 can include comparing a distance between a current location and an event location or an estimated travel time to a threshold. In some instances, process 500 is extended to determine whether the ticket holder has recently been moving and, potentially, to identify a speed and/or direction of the movement. Such information can improve estimations about when the ticket holder may be able to arrive at the event and can be used to provide an estimate as to whether the ticket holder even intends to attempt to attend the event. Those predicted to be unable to attend the event (e.g., unable to arrive by the event's start time or another threshold time), uninterested in attending the event, or unlikely to be able to attend the event can be identified as ticket holders at block 410 for which ticket-surrender offers can be presented to.

FIG. 6 illustrates a flowchart of an embodiment of a process 600 for predicting whether a ticket holder will attend an event. Process 600 begins at block 605, where attendance predictor 240 accesses, from offer database 220, information about an event. The information can identify ticket types for other services or events related to the event (e.g., for admission into a parking area or to a pre-game show). The information can further identify any redemption requirements, such as a check-in requirement (and/or a check-in time requirement).

Attendance predictor 240 accesses, from account database 210, information from an account of a ticket holder. The information can identify other tickets held by the ticket holder likely to be used before attending the event (e.g., vouchers for parking, shuttles, meals, etc.).

At block 615, based on the event and/or event information, attendance predictor 240 identifies one or more actions expected to occur before the event. The actions can include, e.g., redeeming a related ticket (e.g., parking voucher) or checking into the event. At block 620, attendance predictor 240 estimates an absolute or relative time when the one or more actions should occur. For example, redemption of a parking voucher may be estimated to occur 15 minutes before redeeming an event voucher, or redemption of a pre-game show ticket can be estimated to occur at 11 am.

At block 625, attendance predictor 240 determines whether the pre-event action(s) have occurred (e.g., by checking for other ticket-redemption statuses). This determination can be performed at or after a time when it was estimated that the pre-event action should have occurred. Attendance predictor 240 predicts whether the ticket holder will attend the event based on the occurrence status of the pre-event action(s). If the action(s) have not occurred by an expected time or by a threshold amount of time thereafter, it can be predicted that the ticket holder will not be attending the event. Those predicted to be unable to attend the event (e.g., unable to arrive by the event's start time or another threshold time) or unlikely to be able to attend the event can be identified as ticket holders at block 410 for which ticket-surrender offers can be presented to.

FIG. 7 illustrates a flowchart of an embodiment of a process 700 for offering a surrendered ticket to another user. Process 700 begins at block 705, where ticket-offer engine 215 detects that a ticket has been surrendered. It will be appreciated that, in some instances, block 705 can include detecting that a ticket has been conditionally surrendered (e.g., conditioned upon an agreement from another user to purchase the ticket). Ticket-offer engine 215 identifies users who potentially may be interested in owning the surrendered ticket at block 710.

Ticket-offer engine 215 determines details of an offer for the surrendered ticket to present to the identified user(s) at block 715. For example, ticket-offer engine 215 can identify event details (e.g., location and time), a price (which may be less than, the same as or greater than the price of the original ticket), and an offer expiration time. In some instances, the offer further includes specific seat information. In some instances, the offer does not include a price, as acceptance may not be charged (e.g., if a user to whom the offer is presented is in a season-ticket group with an initial ticket holder). The offer can also include an estimate as to a distance and/or time that the user is from the event location and/or an estimate as to an amount of the event that will be missed if he leaves for the event upon receiving the offer. Ticket-offer engine 215 presents an offer with the offer details to the identified user(s) at block 720. The offer can be presented in a manner as described herein (e.g., via a webpage, in an email, in a text message, SMS, MMS, etc.).

Ticket-offer engine 215 determines whether the identified user(s) accepted the offer (e.g., and potentially which of the identified users accepted the offer) at block 725. If the offer is accepted, payment engine 225 initiates payment collection from the appropriate user at block 730. For example, payment engine 225 can collect payment information (e.g., a credit card number and expiration date) and/or collect an agreement to pay a particular amount. In some instances, block 730 is omitted from process 700. Ticket assigner 730 assigns the ticket to the user at block 735 (in a manner described elsewhere herein regarding ticket assignment).

In some instances, a group of potential ticket holders is identified at block 710. Process 700 can perform blocks 715-725 for single potential ticket holders, repeating the blocks until one accepts. In some instances, an offer is simultaneously presented to multiple potential ticket holders, and the ticket is assigned to the first potential ticket holder that accepts the offer. In these instances, when an offer is for a specific seat (or set of seats), the seat tickets may be awarded to the first person who accepts the sales offer. When an offer does not specify a specific seat, and several seat tickets are available, the tickets may be assigned in ranked order based on the order in which the offer acceptances are received. For example, the first user who accepts the sales offer may be assigned the best ranked seats being offered (or the best-priced or best-valued seat), and the second person who accepts the offer may be assigned the second best ranked seats being offered, and so on. An offer may include more than one ticket or set of tickets, at the same or different prices. For example, the offer may include 3 pairs of tickets, each at a different price and of different quality, and the user can select which of the 3 pairs the user wants to purchase.

FIG. 8 illustrates a flowchart of an embodiment of a process 800 for identifying users to whom a surrendered ticket will be offered (e.g., at block 710 in process 700). Process 800 begins at block 805, where ticket-offer engine 215 identifies a set of users. The set of users can include, e.g., all users, all users with an event preference matching a particular event characteristic, all users serving as back-up users for an event or ticket, etc. Locator 245 estimates a location for each user in the set at block 810. The location can include a tracked device location, a home address, etc.

Locator 245 estimates a distance and/or time that each user is from an event location 815. This estimation can involve, e.g., actions similar to those in one or more of blocks 515-530 in process 500. At block 820, attendance predictor 240 estimates which users from the set of users are most likely or likely to be able to attend the event based on the estimated current distance and/or time. At block 825, ticket-offer engine 215 defines potential ticket holder(s) as being those users from the set of users who are estimated to be able to attend the event, such that one or more surrendered tickets can be offered to these users.

FIG. 9 illustrates a flowchart of an embodiment of a process 900 for identifying users to whom a surrendered ticket will be offered (e.g., at block 710 in process 700). Process 900 begins at block 905, where ticket-offer engine 215 presents event information to users. The event information can include an event's name, performing artist/team/athlete, location and/or start time. In some instances, the event information includes a price of a ticket to the event.

Ticket-offer engine 215 informs a user that tickets are no longer available to the event at block 910. The user can be so informed while viewing the event information or upon an attempt to purchase a ticket to the event. However, at block 915, ticket-offer engine 215 offers the user an ability to serve as a back-up ticket holder. Ticket-offer engine 215 can indicate that if a current ticket holder surrenders his ticket, the user could or would then be contacted such that he could acquire the ticket (or such a transfer could occur automatically). The offer could be with respect to a particular ticket (e.g., seat number), group of tickets (e.g., seating zone) or all tickets for the event. The offer may or may not include a fee that would be due in order to serve as a back-up ticket holder.

Ticket-offer engine 215 receives an acceptance of the offer from the user at block 920. For example, block 920 can include detecting that the user clicked on a specific offer link, provided sufficient payment or payment information, called an appropriate number, etc. Ticket-offer engine 215 stores an indication (e.g., in the user's account) that the user will serve as a back-up ticket holder at block 925. The indication can include an identification of the ticket(s) for which the user will serve as a back-up holder for and/or information regarding how to contact the user (e.g., a phone number, a call request, an email address, an email request, etc.).

At block 930, ticket-offer engine 215 defines potential ticket holder(s) as being some or all of the back-up ticket holders, such that one or more surrendered tickets can be offered to these users. In some instances, a subset of the back-up ticket holders is identified to identify those who are close or the closest to an event location, and the potential ticket holders are defined as being the subset.

FIG. 10 illustrates a flowchart of an embodiment of a process 1000 for identifying users to whom a surrendered ticket will be offered. Process 1000 begins at block 1005, where account engine 205 presents users with group options. The group options can include an option to, e.g., join a fan club, a ticket-share club, a season-ticket group, etc. Account engine 205 detects requests to join a group from a first user and from one or more second users at block 1010. The group membership may require a fee, in which case payment can be collected from the users.

Account engine 210 grants group membership to the first and second users and stores indicators of the membership in the respective user accounts at block 1015. Ticket-offer engine 215 detects that the first user surrendered a ticket at block 1020. Ticket-offer engine 215 searches user accounts and identifies the second user(s) as belonging to the same group as the first user at block 1025.

At block 1030, ticket-offer engine 215 defines potential ticket holder(s) as being some or all of the second users, such that one or more surrendered tickets can be offered to these users. In some instances, a subset of the second users is identified to identify those who are close or the closest to an event location, and the potential ticket holders are defined as being the subset.

FIG. 11 illustrates a flowchart of an embodiment of a process 1100 for identifying users to whom a surrendered ticket will be offered. Process 1100 begins at block 1105, where account engine 205 collects event preferences from users. The event preferences can identify types of events that the user likes to attend, preferred event locations, preferred event times (e.g., times of day, days of week, etc.), or preferred artists or athletes (e.g., sports team). The preferences can include those identified by the user during account generation. Account engine 205 stores the preferences in the respective users' accounts at block 1110.

Ticket-offer engine 215 identifies preferences that match an event characteristic (e.g., keyword) at block 1115. Ticket-offer engine 215 searches user accounts and identifies accounts users that have accounts having the select preferences at block 1120.

At block 1125, ticket-offer engine 215 defines potential ticket holder(s) as being some or all of the users having accounts with the select preferences, such that one or more surrendered tickets can be offered to these users. In some instances, a subset of the interest-matching users identified to identify those who are close or the closest to an event location, and the potential ticket holders are defined as being the subset.

It will be appreciated that, in some instances, one or more of processes 800, 1000 and 1100 can be used to identify users to whom an offer for an original ticket can be presented to (e.g., rather than an offer for a surrendered ticket). In this case, e.g., block 1020 of process 1000 can be modified to detect that the first user has purchased a ticket (e.g., thereby allowing other tickets to be offered to those likely interested in the event or interested in attending the event with the first user). The use of one or more of processes 800, 1000 and 1100 with respect to original-ticket offerings can allow system 150 to reach out to users most likely to be interested in attending an event due to their location, event-type preferences, and user relationships. Active ticket promotion can reduce a number of unused tickets. Offers extended through active promotion can be extended during a particular time period (e.g., as an event nears) and/or can include a different ticket price compared to initial ticket offerings.

Referring next to FIG. 12, an exemplary environment with which embodiments can be implemented is shown with a computer system 1200 that can be used by a designer 1204 to design, for example, electronic designs. The computer system 1200 can include a computer 1202, keyboard 1222, a network router 1212, a printer 1208, and a monitor 1206. The monitor 1206, processor 1202 and keyboard 1222 are part of a computer system 1226, which can be a laptop computer, desktop computer, handheld computer, mainframe computer, etc. Monitor 1206 can be a CRT, flat screen, etc.

A designer 1204 can input commands into computer 1202 using various input devices, such as a mouse, keyboard 1222, track ball, touch screen, etc. If the computer system 1200 comprises a mainframe, a designer 1204 can access computer 1202 using, for example, a terminal or terminal interface. Additionally, computer system 1226 can be connected to a printer 1208 and a server 1210 using a network router 1212, which can connect to the Internet 1218 or a WAN.

Server 1210 can, for example, be used to store additional software programs and data. In one embodiment, software implementing the systems and methods described herein can be stored on a storage medium in server 1210. Thus, the software can be run from the storage medium in server 1210. In another embodiment, software implementing the systems and methods described herein can be stored on a storage medium in computer 1202. Thus, the software can be run from the storage medium in computer system 1226. Therefore, in this embodiment, the software can be used whether or not computer 1202 is connected to network router 1212. Printer 1208 can be connected directly to computer 1202, in which case, computer system 1226 can print whether or not it is connected to network router 1212.

With reference to FIG. 13, an embodiment of a special-purpose computer system 1300 is shown. Ticket management system 150 and/or any components thereof are examples of a special-purpose computer system 1300. Thus, for example, one or more special-purpose computer systems 1300 can be used to provide the function of ticket management system 150. The above methods can be implemented by computer-program products that direct a computer system to perform the actions of the above-described methods and components. Each such computer-program product can comprise sets of instructions (codes) embodied on a computer-readable medium that directs the processor of a computer system to perform corresponding actions. The instructions can be configured to run in sequential order, or in parallel (such as under different processing threads), or in a combination thereof. After loading the computer-program products on a general purpose computer system 1226, it is transformed into the special-purpose computer system 1300.

Special-purpose computer system 1300 comprises a computer 1202, a monitor 1206 coupled to computer 1202, one or more additional user output devices 1330 (optional) coupled to computer 1202, one or more user input devices 1340 (e.g., keyboard, mouse, track ball, touch screen) coupled to computer 1202, an optional communications interface 1350 coupled to computer 1202, a computer-program product 1305 stored in a tangible computer-readable memory in computer 1202. Computer-program product 1305 directs system 1300 to perform the above-described methods. Computer 1202 can include one or more processors 1360 that communicate with a number of peripheral devices via a bus subsystem 1390. These peripheral devices can include user output device(s) 1330, user input device(s) 1340, communications interface 1350, and a storage subsystem, such as random access memory (RAM) 1370 and non-volatile storage drive 1380 (e.g., disk drive, optical drive, solid state drive), which are forms of tangible computer-readable memory.

Computer-program product 1305 can be stored in non-volatile storage drive 1390 or another computer-readable medium accessible to computer 1202 and loaded into memory 1370. Each processor 1360 can comprise a microprocessor, such as a microprocessor from Intel® or Advanced Micro Devices, Inc®, or the like. To support computer-program product 1305, the computer 1202 runs an operating system that handles the communications of product 1305 with the above-noted components, as well as the communications between the above-noted components in support of the computer-program product 1305. Exemplary operating systems include Windows® or the like from Microsoft Corporation, Solaris® from Sun Microsystems, LINUX, UNIX, and the like.

User input devices 1340 include all possible types of devices and mechanisms to input information to computer system 1202. These can include a keyboard, a keypad, a mouse, a scanner, a digital drawing pad, a touch screen incorporated into the display, audio input devices such as voice recognition systems, microphones, and other types of input devices. In various embodiments, user input devices 1340 are typically embodied as a computer mouse, a trackball, a track pad, a joystick, wireless remote, a drawing tablet, a voice command system. User input devices 1340 typically allow a user to select objects, icons, text and the like that appear on the monitor 1206 via a command such as a click of a button or the like. User output devices 1330 include all possible types of devices and mechanisms to output information from computer 1202. These can include a display (e.g., monitor 1206), printers, non-visual displays such as audio output devices, etc.

Communications interface 1350 provides an interface to other communication networks and devices and can serve as an interface to receive data from and transmit data to other systems, WANs and/or the Internet 1218. Embodiments of communications interface 1350 typically include an Ethernet card, a modem (telephone, satellite, cable, ISDN), a (asynchronous) digital subscriber line (DSL) unit, a FireWire® interface, a USB® interface, a wireless network adapter, and the like. For example, communications interface 1350 can be coupled to a computer network, to a FireWire® bus, or the like. In other embodiments, communications interface 1350 can be physically integrated on the motherboard of computer 1202, and/or can be a software program, or the like.

RAM 1370 and non-volatile storage drive 1380 are examples of tangible computer-readable media configured to store data such as computer-program product embodiments of the present invention, including executable computer code, human-readable code, or the like. Other types of tangible computer-readable media include floppy disks, removable hard disks, optical storage media such as CD-ROMs, DVDs, bar codes, semiconductor memories such as flash memories, read-only-memories (ROMs), battery-backed volatile memories, networked storage devices, and the like. RAM 1370 and non-volatile storage drive 1380 can be configured to store the basic programming and data constructs that provide the functionality of various embodiments of the present invention, as described above.

Software instruction sets that provide the functionality of the present invention can be stored in RAM 1370 and non-volatile storage drive 1380. These instruction sets or code can be executed by processor(s) 1360. RAM 1370 and non-volatile storage drive 1380 can also provide a repository to store data and data structures used in accordance with the present invention. RAM 1370 and non-volatile storage drive 1380 can include a number of memories including a main random access memory (RAM) to store of instructions and data during program execution and a read-only memory (ROM) in which fixed instructions are stored. RAM 1370 and non-volatile storage drive 1380 can include a file storage subsystem providing persistent (non-volatile) storage of program and/or data files. RAM 1370 and non-volatile storage drive 1380 can also include removable storage systems, such as removable flash memory.

Bus subsystem 1390 provides a mechanism to allow the various components and subsystems of computer 1202 communicate with each other as intended. Although bus subsystem 1390 is shown schematically as a single bus, alternative embodiments of the bus subsystem can utilize multiple busses or communication paths within computer 1202.

Specific details are given in the above description to provide a thorough understanding of the embodiments. However, it is understood that the embodiments can be practiced without these specific details. For example, circuits can be shown in block diagrams in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques can be shown without unnecessary detail in order to avoid obscuring the embodiments.

Implementation of the techniques, blocks, steps and means described above can be done in various ways. For example, these techniques, blocks, steps and means can be implemented in hardware, software, or a combination thereof. For a hardware implementation, the processing units can be implemented within one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, other electronic units designed to perform the functions described above, and/or a combination thereof.

Also, it is noted that the embodiments can be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart can describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations can be re-arranged. A process is terminated when its operations are completed, but could have additional steps not included in the figure. A process can correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination corresponds to a return of the function to the calling function or the main function.

Furthermore, embodiments can be implemented by hardware, software, scripting languages, firmware, middleware, microcode, hardware description languages, and/or any combination thereof. When implemented in software, firmware, middleware, scripting language, and/or microcode, the program code or code segments to perform the necessary tasks can be stored in a machine readable medium such as a storage medium. A code segment or machine-executable instruction can represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a script, a class, or any combination of instructions, data structures, and/or program statements. A code segment can be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, and/or memory contents. Information, arguments, parameters, data, etc. can be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, ticket passing, network transmission, etc.

For a firmware and/or software implementation, the methodologies can be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. Any machine-readable medium tangibly embodying instructions can be used in implementing the methodologies described herein. For example, software codes can be stored in a memory. Memory can be implemented within the processor or external to the processor. As used herein the term “memory” refers to any type of long term, short term, volatile, nonvolatile, or other storage medium and is not to be limited to any particular type of memory or number of memories, or type of media upon which memory is stored.

Moreover, as disclosed herein, the term “storage medium” can represent one or more memories for storing data, including read only memory (ROM), random access memory (RAM), magnetic RAM, core memory, magnetic disk storage mediums, optical storage mediums, flash memory devices and/or other machine readable mediums for storing information. The term “machine-readable medium” includes, but is not limited to portable or fixed storage devices, optical storage devices, wireless channels, and/or various other storage mediums capable of storing that contain or carry instruction(s) and/or data.

While the principles of the disclosure have been described above in connection with specific apparatuses and methods, it is to be clearly understood that this description is made only by way of example and not as limitation on the scope of the disclosure. 

1. A ticket management system for estimating user locations and presenting location-sensitive ticket offers, the ticket management system comprising: a ticket database that identifies, for each ticket in a set of tickets for an event, an assignment indicating whether the ticket has been assigned to a user and an identifier of any user to whom the ticket is assigned; an offer database that identifies a location and a time of the event; a locator that: accesses the offer database to identify the location of an event and the time of the event, receives a signal from each of a plurality of transmitters, each of the plurality of transmitters including a global positioning satellite, a Wi-Fi access point or a cell phone tower; and estimates, at a time prior to the time of the event, a current location of a mobile device of a user based on the signals from the plurality of transmitters; an attendance predictor that predicts whether the user will be able to attend the event, the prediction being based on the location of the event, the time of the event and the estimated current location of the user; an offer engine that: determines, based on the prediction of whether the user will be able to attend the event, that an offer is to be presented to the user, generates the offer, the offer indicating that acceptance of the offer will cause an assignment of a ticket of the set of tickets for the event to change, presents the offer to the user; and detects an acceptance of the offer from the user; and a ticket assigner that, in response to the detection of the acceptance, changes the assignment of the ticket in the ticket database.
 2. The ticket management system for estimating user locations and presenting location-sensitive ticket offers as recited in claim 1, wherein: the offer engine comprises a surrender-offer engine that determines that the offer is to be presented to the user when the attendance predictor predicts that the user will not be able to attend the event, the ticket is, prior to the acceptance, assigned to the user, the offer is an offer to surrender the ticket, and the ticket assigner changes the assignment of the ticket by removing the assignment.
 3. The ticket management system for estimating user locations and presenting location-sensitive ticket offers as recited in claim 2, further comprising: a ticket-offer engine that: generates a second offer, presents the second offer to a second user, and detects a second acceptance of the second offer from the second user, wherein the ticket assigner, in response to the detection of the second acceptance, assigns the ticket to the second user in the ticket database.
 4. The ticket management system for estimating user locations and presenting location-sensitive ticket offers as recited in claim 2, wherein the detected acceptance of the offer is a conditioned acceptance, the acceptance being conditioned upon another user agreeing to purchase the ticket, and wherein the assignment is only changed upon occurrence of the another user agreeing to purchase the ticket.
 5. (canceled)
 6. (canceled)
 7. The ticket management system for estimating user locations and presenting location-sensitive ticket offers as recited in claim 1, further comprising an account database including a plurality of accounts, wherein: each account corresponds to a respective user, at least one account of the plurality of accounts includes a variable indicating that the respective user is to serve as a back-up ticket holder for the event, the offer engine queries the account database for an account with the variable indicating that the respective user is to serve as a back-up ticket holder for the event, the user is identified based on the query, the offer is an offer to have a right to use the ticket, and the ticket assigner changes the assignment of the ticket by assigning the ticket to the user.
 8. A method for estimating user locations and presenting location-sensitive ticket offers, the method comprising: accessing an offer database that identifies a location and a time of an event; identifying, based on the access to the offer database, the location and time of the event; receiving a signal from each of a plurality of transmitters, each of the plurality of transmitters including a global positioning satellite, a Wi-Fi access point or a cell phone tower; estimating, at a time prior to the time of the event, a current location of a mobile device of a user based on the signals from the plurality of transmitters; predicting whether the user will be able to attend the event, the prediction being based on the location of the event, the time of the event and the estimated current location of the user; determining, based on the prediction of whether the user will be able to attend the event, that an offer is to be presented to the user, generating the offer, the offer indicating that acceptance of the offer will cause an assignment of a ticket of a set of tickets for the event to change in a ticket database, the ticket database identifying, for each ticket in the set of tickets for the event, an assignment indicating whether the ticket has been assigned and an identifier of any user to whom the ticket is assigned; presenting the offer to the user; detecting an acceptance of the offer from the user; and changing, in response to the detection of the acceptance, the assignment of the ticket in the ticket database.
 9. The method for estimating user locations and presenting location-sensitive ticket offers as recited in claim 8, wherein: determining that the offer is to be presented comprises determining that the offer is to be presented to the user when the attendance predictor predicts that the user will not be able to attend the event, the ticket is, prior to the acceptance, assigned to the user, the offer is an offer to surrender the ticket, and changing the assignment comprises removing the assignment.
 10. The method for estimating user locations and presenting location-sensitive ticket offers as recited in claim 9, further comprising: generating a second offer; presenting the second offer to a second user; detecting a second acceptance of the second offer from the second user; and assigning, in response to the detection of the second acceptance, the ticket to the second user in the ticket database.
 11. The method for estimating user locations and presenting location-sensitive ticket offers as recited in claim 9, wherein the detected acceptance of the offer is a conditioned acceptance, the acceptance being conditioned upon another user agreeing to purchase the ticket, and wherein the assignment is only changed upon occurrence of the another user agreeing to purchase the ticket.
 12. (canceled)
 13. (canceled)
 14. The method for estimating user locations and presenting location-sensitive ticket offers as recited in claim 8, further comprising: querying an account database for an account from amongst a plurality of accounts with the variable indicating that a respective user of the account is to serve as a back-up ticket holder for the event; and identifying the user based on the query, wherein the offer is an offer to have a right to use the ticket, and wherein changing the assignment of the ticket comprises assigning the ticket to the user.
 15. A ticket management system for estimating user locations and presenting location-sensitive ticket offers, the ticket management system comprising: one or more processors; and one or more memories coupled with the one or more processors, wherein the one or more processors and one or more memories are configured to: access an offer database that identifies a location and a time of an event; identify, based on the access to the offer database, the location and time of the event; receive a signal from each of a plurality of transmitters, each of the plurality of transmitters including a global positioning satellite, a Wi-Fi access point or a cell phone tower; estimate, at a time prior to the time of the event, a current location of a mobile device of a user based on the signals from the plurality of transmitters; predict whether the user will be able to attend the event, the prediction being based on the location of the event, the time of the event and the estimated current location of the user; determine, based on the prediction of whether the user will be able to attend the event, that an offer is to be presented to the user; generate the offer, the offer indicating that acceptance of the offer will cause an assignment of a ticket of a set of tickets for the event to change in a ticket database, the ticket database identifying, for each ticket in the set of tickets for the event, an assignment indicating whether the ticket has been assigned and an identifier of any user to whom the ticket is assigned; present the offer to the user; detect an acceptance of the offer from the user; and change, in response to the detection of the acceptance, the assignment of the ticket in the ticket database.
 16. The ticket management system for estimating user locations and presenting location-sensitive ticket offers as recited in claim 15, wherein: determining that the offer is to be presented comprises determining that the offer is to be presented to the user when the attendance predictor predicts that the user will not be able to attend the event; the ticket is, prior to the acceptance, assigned to the user; the offer is an offer to surrender the ticket; and changing the assignment comprises removing the assignment.
 17. The ticket management system for estimating user locations and presenting location-sensitive ticket offers as recited in claim 16, wherein the one or more processors and one or more memories are further configured to: generate a second offer; present the second offer to a second user; detect a second acceptance of the second offer from the second user; and assign, in response to the detection of the second acceptance, the ticket to the second user in the ticket database.
 18. The ticket management system for estimating user locations and presenting location-sensitive ticket offers as recited in claim 16, wherein the detected acceptance of the offer is a conditioned acceptance, the acceptance being conditioned upon another user agreeing to purchase the ticket, and wherein the assignment is only changed upon occurrence of the another user agreeing to purchase the ticket.
 19. (canceled)
 20. The ticket management system for estimating user locations and presenting location-sensitive ticket offers as recited in claim 15, wherein the one or more processors and one or more memories are further configured to: query an account database for an account from amongst a plurality of accounts with the variable indicating that a respective user of the account is to serve as a back-up ticket holder for the event; and identify the user based on the query, wherein the offer is an offer to have a right to use the ticket, and wherein changing the assignment of the ticket comprises assigning the ticket to the user.
 21. The ticket management system for estimating user locations and presenting location-sensitive ticket offers as recited in claim 1, wherein the attendance predictor predicts whether the user will be able to attend the event, at least in part by: identifying a distance between the current location and the location of the event; or estimating a commute time between the current location and the location of the event.
 22. The ticket management system for estimating user locations and presenting location-sensitive ticket offers as recited in claim 1, wherein the attendance predictor predicts whether the user will be able to attend the event at a defined time prior to the time of the event.
 23. The method for estimating user locations and presenting location-sensitive ticket offers as recited in claim 8, wherein predicting whether the user will be able to attend the event includes: identifying a distance between the current location and the location of the event; or estimating a commute time between the current location and the location of the event.
 24. The method for estimating user locations and presenting location-sensitive ticket offers as recited in claim 8, wherein the predicting whether the user will be able to attend the event occurs at a defined time prior to the time of the event
 25. The ticket management system for estimating user locations and presenting location-sensitive ticket offers as recited in claim 15, wherein predicting whether the user will be able to attend the event includes: identifying a distance between the current location and the location of the event; or estimating a commute time between the current location and the location of the event. 